Копировать руками машину каждый раз, когда нужно внедрить какое-то оборудование, или просто для сохранения данных, это безумно неудобно. Вот для этого и была придумана технология автоматизированного бэкапа, написанная энтузиастами на скриптах perl: ghettoVCB.

Вы все уже вполне себе знаете, что есть на свете замечательный продукт StarWind Enterprise 5.6, который позволяет создавать отказоустойчивое хранилище для виртуальных машин VMware vSphere / Microsoft Hyper-V на базе технологии iSCSI, что не требует больших вложений и отлично подходит для небольших компаний и филиалов, где дорого и нецелесообразно покупать громоздкие Fibre Channel массивы (да и, вообще, FC вымирает потихоньку, особенно с приходом 10G Ethernet). О StarWind у нас есть специальный раздел, а также рекомендую почитать тут, тут и тут.

Сегодня мы поговорим о том, какие еще возможности существуют в StarWind Enterprise при работе с дисками (см. предыдущую статью). Во-первых, при создании образа виртуального диска можно задать опцию шифрования данных, которая позволит вам повысить безопасность инфраструктуры хранения виртуальных машин:

Во-вторых, в StarWind iSCSI Target есть возможность расширить уже существующее хранилище. Для этого нужно просто нажать правой кнопкой на файл образа виртуального диска и выбрать пункт "Extend Image Size":

Расширим наше хранилище с 10 до 15 ГБ:

Данная операция не повреждает хранилище с виртуальными машинами. После расширения образа виртуального диска с хранилищем VMFS, в VMware vSphere вам нужно будет сделать расширение тома. Выбираем Properties для нашего Datastore:

И нажимаем кнопку Increase:

Выбираем наш том:

И расширяем его:

Хранилище VMFS расширено на 5 ГБ:

Вот так легко и непринужденно можно оперировать с томами StarWind Enterprise iSCSI. Скачать продукт можно по этой ссылке. Нормальные ребята покупают его тут.

Как вы знаете в последнем релизе платформы виртуализации VMware vSphere 4.1 было заявлено множество новых возможностей. Одна из них весьма важна с точки зрения производительности в части работы виртуальных машин с системой хранения. Эта технология называется VMware vSphere VAAI, то есть vStorage API for Array Integration.

Итак, что такое VMware vSphere VAAI. Это комплекс технологий компании VMware, разработанный в сотрудничестве с производителями дисковых массивов (потому и API), предназначенный для передачи некоторых операций виртуальных машин по работе с дисками на сторону массива. В этом случае хост-сервер виртуализации VMware ESX / ESXi при выполнении стандартных процедур в среде виртуализации при работе ВМ с дисковой подсистемой просто дает команду массиву (или массивам) сделать определенные действия, при этом сам хост не гонит через себя все те данные и команды, которые он раньше был вынужден прогонять. То есть, это - Hardware Offloading операций с СХД.

Ну а раз это аппаратно-зависимая вещь, то это означает, что сам массив должен в своем Firmware поддерживать vSphere VAAI (у которой еще бывает несколько видов - так называемые "примитивы"). Чтобы узнать поддерживает ли ваш хост VAAI нужно пойти в VMware Hardware Compatibility Guide и поискать свой дисковый массив в категории "Storage/SAN". Там все сделано несколько криво, но нужно искать в Supported Releases следующую сноску:

VAAI primitives "Full Copy", "Block Zeroing" and "Hardware Assisted Locking" are supported with vmw_vaaip_xxx plug-in

xxx - это идентификатор плагина от VMware

Ну и, конечно, ваш хост VMware ESX / ESXi должен быть версии 4.1 или выше. И помните, что на некоторых массивах VAAI по умолчанию выключена, поэтому вам нужно почитать документацию о том, как ее включить. Кроме того, функциональность VMware vSphere VAAI есть только в изданиях VMware vSphere Enterprise и Enterprise Plus (см. сравнение изданий).

Теперь, какие примитивы (то есть типовые операции с СХД) реализует VMware vSphere VAAI:

• Full Copy / Clone Blocks / XCOPY  – функция, позволяющая передать на сторону массива возможности копирования объектов виртуальной инфраструктуры без задействования операций четния-записи со стороны сервера VMware ESX 4.1. Эту функцию также называют Hardware Offloaded Copy и SAN Data Copy Offloading.
• Write Same / Zero Blocks – возможность обнуления больших массивов блоков на дисковых устройствах для быстрого создания дисков vmdk типа eager zero thick.
• Atomic Test and Set (ATS) –возможность защиты метаданных тома VMFS как кластерной файловой системы в ситуациях, когда большое количество хостов ESX имеют разделяемый доступ к одному хранилищу. Также эта функция называется Hardware Assisted Locking.

Давайте рассмотрим как эти компоненты VAAI работают и для чего они нужны.

Full Copy

Используя этот примитив, дисковый массив по команде VMware vSphere осуществляет копирование виртуальной машины (а самое главное для нас копирование диска VMDK) без участия сервера ESX / ESXi и его стека работы с подсистемой хранения (соответственно, не гоняется трафик и не дается нагрузка на CPU). В этом случае гипервизор рассказывает хранилищу, какие блоки занимает виртуальная машина, а оно уже делает все остальное по копированию блоков.

Виртуальная машина может копироваться как в пределах одного хранилища, так и между двумя массивами, если они поддерживают функциональность XCopy. Наиболее интересный способ применения данной техники - это массовое развертывание виртуальных машин из шаблонов, которое больше всего востребовано в VDI-инсталляциях (например, в решении для виртуализации корпоративных ПК предприятия VMware View 4.5).

Еще один важный аспект применения - операция Storage vMotion, которая требует копирования виртуальных дисков машины.

С vSphere VAAI операции по копированию блоков данных хранилищ виртуальных машин занимают меньше времени (в некоторых случаях оно сокращается на 95%):

Ну а вот такие результаты нам выдает Storage vMotion:

Кроме того, данная технология интегрирована и с функциональностью "тонких" (thin) дисков как самой VMware, так и механизмом Thin Provisioning сторонних вендоров.

Write Same / Zero Blocks

За счет этой технологии сервер VMware ESX / ESXi может дать команду хранилищу обнулить блоки виртуальных дисков типа Eager zeroed thick (см. типы дисков). Эти диски являются самыми безопасными (блоки чистятся при создании) и самыми производительными (при обращении к блоку его не надо обнулять и тратить ресурсы), но занимали очень много времени на их создание. Теперь с техникой VAAI этот процесс сильно ускоряется, что позволяет использовать диски eagerzeroedthick чаще (например, для машин с включенной Fault Tolerance). Напомню, что сейчас по умолчанию в VMware vSphere создаются диски типа Zeroed thick disks.

Теперь одинаковые команды ввода-вывода на сторадж от сервера ESX / ESXi дедуплицируются, а массиву дается команда на повторение одинаковых команд для разных блоков. На эту тему есть отдельное видео:

Atomic Test and Set (ATS) или Hardware Assisted Locking

За счет этой техники vSphere VAAI существенно уменьшается число операций с хранилищем, связанных с блокировкой LUN на системе хранения. Как вы знаете, при работае виртуальных машин возникают конфликты SCSI Reservations, связанные с тем, что некоторые операции вызывают блокировку всего LUN для обновления метаданных тома VMFS. Операций этих много: запуск виртуальной машины (обновляется lock и создаются файлы), развертывание новой ВМ, создание снапшота, миграция vMotion и т.п.

Нехорошо также, что при использовании тонких дисков (например для связанных клонов VMware View) также происходит блокировка LUN при выделении нового блока растущему диску (надо обновлять метаданные - см. тут). Это, прежде всего, приводит к тому, что возникает ограничение на количество размещаемых на LUN виртуальных машин, чтобы конфликтов SCSI Reservations не было слишком много.

Теперь же, за счет VAAI, эти операции передаются на сторону дискового массива, который при необходимости обновить метаданные тома не блокирует весь LUN, а лочит только секторы метаданных, которые требуется обновить. Все это делается массивом безопасно и надежно. Отсюда вытекает уменьшение числа конфликтов SCSI Reservations и ,как следствие, лучшая производительность и увеличения числа ВМ на LUN.

Ограничения VMware vSphere VAAI

Недавно мы писали про Data Mover'ы - это компоненты VMware ESX / ESXi, отвечающие за работу хост-сервера с хранилищами при копировании данных. Поддержкой VAAI заведует компонент fs3dm – hardware offload. Он пока еще молодой, поэтому не поддерживает некоторых сценариев использования. Соответственно все или некоторые техники VAAI у вас не будут работать в следующих случаях:

• Исходный и целевой тома VMFST имеют разные размеры блоков
• Исходный файл лежит на том RDM, а целевое хранилище - это не том RDM 
• Исходный тип диска VMDK - это eagerzeroedthick, а целевой - thin
• Исходный или целевой тип диска VMDK VMDK - один из типов sparse или hosted (не платформа vSphere)
• Исходная виртуальная машина имеет снапшот 
• Блоки хранилища, где лежит виртуальная машина не выровнены (по умолчанию vSphere Client выравнивает блоки автоматически)

Как включить VMware vSphere VAAI

Как уже было сказано выше, со стороны хранилищ VAAI может быть выключена и нужно почитать документацию на СХД. На хостах ESX / ESXi по умолчанию VAAI включена. Проверить это можно, перейдя в Configuration > Advanced Settings и увидев следующие параметры, напротив которых стоят единицы:

• DataMover/HardwareAcceleratedMove (это возможности Full Copy)
• DataMover/HardwareAcceleratedInit (это Zero Block)
• VMFS3/HardwareAcceleratedLocking (это ATS)

Или можно проверить из командной строки:

# esxcfg-advcfg -g /DataMover/HardwareAcceleratedMove
# esxcfg-advcfg -g /DataMover/HardwareAcceleratedInit
# esxcfg-advcfg -g /VMFS3/HardwareAcceleratedLocking

Если ваше хранилище не поддерживает VAAI - ничего страшного, хост ESX / ESXi будет работать софтовыми дедовскими методами.

Как проверить, работает ли vSphere VAAI?

Очень просто, откройте категорию Storage на вкладке Configuration в vSphere Client и посмотрите в последний столбик.

Статус Unknown означает, что хост еще не обращался к операциям, которые поддерживаются VAAI (то есть, это дефолтный статус). Если вы сделаете какую-нибудь операцию с VAAI (например, Copy/Paste виртуального диска больше 4 МБ), то VAAI попробует отработать. Если он отработает успешно - выставится статус Supported, ну а если нет - то Not Supported.

Опросить стораджи можно также из командной строки:

# esxcfg-scsidevs -l | egrep "Display Name:|VAAI Status:"

Вывод будет похожим на это:

Display Name: Local VMware Disk (mpx.vmhba2:C0:T0:L0)
VAAI Status: unsupported
Display Name: Local USB CD-ROM (mpx.vmhba32:C0:T0:L0)
VAAI Status: unknown
Display Name: Local TEAC CD-ROM (mpx.vmhba3:C0:T0:L0)
VAAI Status: unknown
Display Name: DGC Fibre Channel Disk (naa.6006016030801c00f8506073d0d7de11)
VAAI Status: unknown
Display Name: DGC Fibre Channel Disk (naa.6006016030801c00f9506073d0d7de11)
VAAI Status: unknown

Дополнительная информация о vSphere VAAI

Обзорное видео:

Демо от EMC:

Демо от HP:

Демо от NetApp:

Документы:

vStorage APIs for Array Integration FAQ

What's New in VMware vSphere 4.1 — Storage

Как мы уже писали, в VMware vSphere 4.1 появилась технолония Storage IO Control (SIOC, подробности здесь), которая позволяет настраивать приоритеты доступа виртуальных машин к хранилищам не в рамках одного хоста VMware ESX / ESXi, а в рамках всего кластера.

Первый документ "Storage I/O Control Technical Overview and Considerations for Deployment" рассказывает нам о том, как именно работает данная технология:

как ее нужно настраивать:

и какие рекомендации по настройкам Latency можно использовать при борьбе виртуальных машин за ресурсы ввода-вывода, в зависимости от типов хранилищ:

Второй документ называется "Managing Performance Variance of Applications Using Storage I/O Control". Он содержит результаты тестирования SIOC в условиях, когда нужно выделить виртуальную машину как критичную с точки зрения ввода-вывода (отмечена звездочкой). Взяли требовательную к нагрузкам задачу (DVD Store).

Измерили эталонную производительность когда работает только критичная ВМ (левый столбик - принят за единицу, SIOC Off), измерили среднуюю производительность (когда все машины работают параллельно и у каждой Shares установлено в 1000, SIOC Off), а потом стали варьировать Shares для критичной виртуальной машины (при включении SIOC On) смотря на то, как растет ее производительность в рамках кластера:

Видим, что SIOC при распределении приоритета ввода-вывода между хостами работает. В этом же документе есть еще тесты, посмотрите.

Напоминаю, что технология VMware Storage IO Control есть только в издании VMware vSphere Enterprise Plus.

Как вы знаете, для виртуальных хранилищ (datastores) в VMware vSphere есть возможность задавать разные размеры блоков тома VMFS. Также вы, вероятно, знаете, что операция Storage vMotion позволяет перемещать виртуальную машину между хранилищами, превращая ее виртуальный диск из толстого (thick) в тонкий (thin).

Но чтобы это результирующий тонкий диск после Storage vMotion занимал на целевом хранилище только столько пространства, сколько используется внутри гостевой ОС (а не весь заданный при создании), нужно предварительно почистить блоки с помощью, например, утилиты sdelete.

Duncan Epping, известный технический эксперт VMware, обратил внимание на проблему, когда пользователь делает очистку блоков, затем Storage vMotion, а уменьшения диска не происходит. Почему так?

Очень просто, в составе VMware ESX / ESXi есть три типа datamover'ов ("перемещателей"):

• fsdm – это старый datamover, который представляет собой базовую версию компонента. Он работает сквозь все уровни, обозначенные на картинке. Зато он, как всегда, универсален.
• fs3dm – этот datamover появился в vSphere 4.0 и имеет множество оптимизаций. И вот тут данные уже не идут через стек работы с виртуальной машиной. То есть он работает быстрее.
• fs3dm – hardware offload – Этот компонент появился для поддержки технологии VAAI, которая позволяет вынести операции по работе с хранилищами виртуальных машин на сторону массива (hardware offload). Он, естественно, самый быстрый и не создает нагрузку на хост VMware ESX / ESXi.

Так вот основная мысль такова. Когда вы делаете миграцию Storage vMotion виртуальной машины между хранилищами с разными размерами блоков используется старый datamover fsdm, а когда с одинаковыми, то новый fs3dm (в программном или аппаратном варианте). Последний работает быстрее, но не умеет вычищать нулевые блоки на целевом хранилище у виртуального диска VMDK.

А вот старый fsdm, ввиду своей универсальности, это делать умеет. То есть, если нужно вычистить нулевые блоки не перемещайте ВМ между хранилищами с одинаковыми размерами блоков. Так-то вот.

Как вы знаете, у компании Veeam есть замечательный продукт Veeam Backup and Replication 5, который умеет делать не только резервные копии и восстановление виртуальных машин, но и репликацию, и виртуальные тестовые лаборатории, и напрямую может запускать ВМ из резервных копий. А сегодня мы посмотрим еще на один модуль - Veeam Search Server, тем более, что поставить его не так просто.

Вы уже все знаете про компанию StarWind Software и ее замечательный продукт StarWind Enterprise 5.6 для создания отказоустойчивых хранилищ для виртуальных машин VMware vSphere и Hyper-V. О нем написано в нашем разделе, но для начала можно почитать тут, тут и тут.

О новых возможностях StarWind Enterprise 5.6 мы уже писали, а сам продукт можно скачать здесь. Напомню, что важной новой фичей является поддержка дедупликации хранилищ для виртуальных машин, что в будущем будет вам здорово экономить деньги.

Есть еще одна деталь в плане оптимизации быстродействия. Раньше сихронизация между узлами отказоустойчивого хранилища StarWind проходила медленнее, чем в версии 5.6. Это связано с тем, что раньше для всех iSCSI таргетов операции по синхронизации ставились в общую очередь, что вызывало непоследовательную запись данных на дисковые устройства (данные писались в разнобой). Теперь все сделано грамотно - каждый таргет синхронизирует свои данные в своем последовательном потоке, потом приступает к снихронизации второй. Удобно и быстро.

Далее. Тестируйте дедупликацию, пишите о результатах. Версия StarWind Enterprise 5.7 уже не за горами. В недрах девелоперских копей зреют идеи по созданию QoS-приоритетов для канала синхронизации и канала доступа хостов к хранилищам и много чего еще.

Теперь. Все быстренько пошли на сайт Network Computing Awards 2011, выбрали "Vote Now" в левом меню и проголосовали в категории "Storage Product of the year" за StarWind Enterprise. Надо болеть за наших ребят.

Часто разговаривая с заказчиками и пользователями платформ виртуализации от VMware, я вижу, что у многих из них весьма широко применяются снапшоты (snapshots), в том числе для целей "резервного копирования". Эти снапшоты живут долго, их файлы разрастаются и поростают плесенью. Потом инфраструктура начинает тормозить, а пользователи не знают почему. И как это не казалось бы странным - удаление всех снапшотов у всех виртуальных машин решает их проблемы, с которыми они уже свыклись.

Сегодня я вам расскажу, чтоб вы наконец запомнили: снапшоты это в целом плохо и лишь иногда хорошо. На эту страницу мы с вами будем отсылать наших клиентов и пользователей виртуальных машин, которыми могут оказаться люди, не участвующие в процессе администрирования VMware vSphere, но пользующиеся функционалом снапшотов (например, веб-разработчики).

Начнем с того, когда снапшоты могут помочь (я имею в виду, конечно, руками делаемые снапшоты, а не автоматические, которые делает, например, Veeam Backup).  Снапшоты в VMware vSphere оказываются полезны в очень ограниченных условиях (например, для проверки корректности работы обновления приложения или патча операционной системы). То есть эта та точка сохранения состояния виртуальной машины, к которой можно будет вернуться через небольшой промежуток времени. Ни в коем случае нельзя рассматривать снапшоты как альтернативу резервному копированию основных производственных систем, в силу множества проблем, о которых пойдет речь ниже.

Что плохого в снапшотах виртуальных машин на VMware ESX:

1. Снапшоты неконтролируемо растут (блоками по 16 МБ). Помимо базового диска ВМ фиксированной емкости вы имеете еще один файл отличий виртуального диска, который растет как ему вздумается (предел роста одного снапшота - размер базового диска). Особенно быстро растут снапшоты для ВМ с приложениями с большим количеством транзакций (например, почтовый сервер или сервер СУБД). Со снапшотами вы не имеете контроля над заполненностью хранилищ.

2. Большое количество снапшотов (особенно цепочки, в которых может быть до 32 штук) вызывает тормоза виртуальной машины и хост-сервера ESX (в основном замедляется работа с хранилищем). Проверено на практике. Даже VMware пишет так: "An excessive number of snapshots in a chain or snapshots large in size may cause decreased virtual machine and host performance". В качестве примера можно привести тот факт, что при аллокации блоков снапшота происходит блокировка LUN (в этом режиме он доступен только одному хосту, остальные ждут). Когда снапшот делается - машина подвисает из-за сброса памяти на диск.

3. Снапшоты не поддерживают многие технологии VMware, созданные для автоматизации датацентров. К ним относятся VMware Fault Tolerance, Storage VMotion и другие. Когда одни машинки в чем-то участвуют, а другие не участвуют - это нехорошо в рамках концепции динамической инфраструктуры.

4. Снапшоты вызывают специфические проблемы при операциях с ВМ. Например, расширение диска виртуальной машины со снапшотом приводит к потере данных и непонятками, что дальше с такой машиной делать. Сто раз уже пользователи влипали (вот как вытянуть себя за волосы). Интересно также восстановить из снапшота машину с IP-адресом, который на данный момент уже используется в сети.

5. Со снапшотами бывают баги, а бывает, что они просто "by design" тупят.

6. У снапшотов было плохое поведение при их слиянии, но сейчас исправилось.

Рекомендации по работе со снапшотами:

1. Контролируйте наличие снапшотов у виртуальных машин и их размеры, своевременно удаляйте их совместно с владельцами систем. Делать это можно, например, с помощью RVTools.

2. Не храните снапшоты больше 24-72 часов. Этого времени достаточно, чтобы оттестировать обновление ПО или патч ОС (ну и, конечно, сделать бэкап).

3. На сервере VMware vCenter можно настроить алармы на снапшоты виртуальных машин. Сделайте это. Дрючьте пользователей за необоснованные снапшоты.

4. Не позволяйте делать больше 2-3 снапшотов для виртуальной машины в принципе, если это делается в производственной среде. На своих выделенных для тестирования ресурсах (изолированных) пусть разработчики делают что хотят.

5. Если вы используете ПО для резервного копирования через снапшоты ВМ (например, Veeam Backup), помните, что бывает некоторые невидимые в vSphere Client снапшоты (Helpers) остаются на хранилище. Поглядывайте за машинами из командной строки.

6. Почитайте: KB 1009402, KB 1025279, KB 1015180.

Если вы используете пулы типа Linked Clone (на основе базового образа) в решении для виртуализации ПК VMware View 4.5, то знаете, что есть такая операция "Rebalance", которая перераспределяет виртуальные ПК пула по хранилищам VMFS / NFS. Но многие удивятся, как работает эта функция. Например, у вас есть несколько хранилищ различной емкости, и вы делаете Rebalance десктопов.

Получаете вот такую картину:

Слева - то, что вы ожидаете увидеть в результате балансировки, а справа - то, что получается на самом деле. В чем причина?

Все дело в том, что VMware View 4.5 использует для перемещения машин на хранилище параметр "weighted available space". У какого из хранилищ он больше - туда виртуальные машины и переезжают. Что это за параметр:

weighted_available_space = datastore_capacity * overcommit_factor – virtual_usage

Здесь:

datastore_capacity - это общая емкость хранилища VMFS / NFS.

virtual_usage - это максимально возможный объем, занимаемый виртуальными машинами на хранилище, который формируется из размера виртуальных дисков машин (номинального, а не реального) + размер памяти (для Suspend).

overcommit_factor - это настройка для Storage Overcommit, которую вы задавали для Datastore, когда выбирали, какие из них следует использовать для пулов Linked Clone. Там были такие значения:

• None - хранилище не является overcommitted.
• Default - это коэффициент 4 от размера хранилища
• Moderate - это коэффициент 7 от размера хранилища
• Aggressive - это коэффициент 15 от размера хранилища.

Теперь переходим к примеру и формуле. Есть у нас вот такая картинка (см. настройки overcommitment):

Счтиаем weighted available space:

• DS1 - 1000GB (Datastore Size) * 4 (Conservative Overcommitment) – 0 (No VM's deployed) = 4000
• DS2 - 1000GB (Datastore Size) * 4 (Conservative Overcommitment) – ((20GB + 130MB)x5) (5 VM's already deployed) = 3865
• DS3 - 1000GB (Datastore Size) * 7 (Moderate Overcommitment) – ((20GB + 130MB)x5) (5 VM's already deployed) = 6865

Теперь вот вам задачка - что будет в результате Rebalance виртуальных ПК?

По-сути, правило таково: если у вас все хранилища с одинаковым уровнем Storage Overcommitment и одинакового размера, то виртуальные машины будут перемещены на другие хранилища, если там больше свободного места, чем свободного места на текущем хранилище. Ну а если разного размера и одинакового уровня Overcommitment - то ожидайте того, что машины останутся на больших хранилищах. Так-то вот.

И да, никогда не далейте Storage VMotion для виртуальных машин VMware View 4.5 вручную - это не поддерживается со стороны VMware.

Материал написан по мотивам заметки "VMware View 4.5: Rebalance" от Simon Long.

Мы уже писали о новых возможностях StarWind Enterprise 5.6, которые будут доступны для пользователей в самое ближайшее время с выходом новой версии (ожидается к 10 февраля, не забываем кстати про раздел о StarWind на нашем сайте). Но ребята подсуетились и успели добавить еще одну важную и нужную в будущем возможность - блочную дедупликацию виртуальных дисков для хранилищ iSCSI с виртуальными машинами:

Как вы видите, пока данная функциональность отмечена звездочкой, что значит, что возможность дедупликации находится в экспериментальном режиме, и для производственных данных использовать ее не надо. Но для тестирования - вполне. Дедупликация в StarWind iSCSI Target позволит снизить требуемый объем хранилищ для виртуальных машин (а особенно для однотипных нагрузок), что снизит общие затраты на содержание виртуальной инфраструктуры.

При создании дедуплицированного образа виртуального диска для хранения виртуальных машин StarWind Enterprise сам пытается получить настройки дедуплицированного хранилища.

Поэтому значения на следующей странице менять не нужно, оставьте как есть (либо меняйте их вместе с сотрудником техподдержки StarWind):

Скачать StarWind Enterprise 5.6 можно будет где-то в районе 10 февраля.

Ricky El-Qasem, автор сайта VirtualizePlanet.com, выпустил интересную бесплатную утилиту для VMware vSphere - vDisk Informer. Эта утилита решает две важные проблемы:

1. Поиск виртуальных машин, дисковое пространство которых используется неэффективно, попросту говоря, много свободного места:

При сканировании виртуальной инфраструктуры можно задавать объем в ГБ или МБ, начиная с которого будут отображаться соответствующие иконки, говорящие нам о том, что можно уменьшить диск виртуальной машины.

2. Вторая функция нужнее - она позволяет определить виртуальные машины, у которых наблюдается проблема некорректного выравнивания блоков дисков VMDK (например, после P2V-миграции). Можно также задавать параметры смещения - 32K или 64K (в зависимости от SAN-массива, где лежат ваши ВМ):

Скачать vDisk Informer можно по этой ссылке. Видео о возможностях здесь.

На днях мне досталась бета-версия продукта StarWind Enterprise 5.6 (сейчас актуальна версия 5.5), средства создания отказоустойчивых iSCSI-хранилищ для виртуальных машин VMware vSphere и Microsoft Hyper-V. Мы уже много писали об этом замечательном продукте (тут, тут и тут), а сегодня посмотрим что нового появится в StarWind 5.6, который выйдет в ближайшем будущем.

Во-первых, появилась вкладка "Events", где системный администратор может отслеживать события и ошибки происходящии в инфраструктуре отказоустойчивого кластера StarWind iSCSI Target для каждого из узлов:

Во-вторых, появилась нотификация администраторов по email о различных предупреждениях и событиях (интерфейс еще не совсем готов в моей версии). Эти события также добавляются в Windows Event Log, а также можно писать их в текстовый файл.

Ну и, в третьих, пароль для логина на сервер StarWind в Management Console можно сохранять (мелочь, но приятно - раньше было неудобно):

Как всегда, обновление с версии 5.5 на версию 5.6 проходит без необходимости полной переустановки ПО и перезагрузки сервера (т.е. новая версия просто накатывается поверх). Как обновить продукт StarWind Enterprise HA на версию 5.6:

1. Сначала обновляем первый узел кластера StarWind Enterprise HA.

2. Затем синхронизируем ноды между собой (обязательно дождаться окончания процесса).

3. Обновляем второй узел и снова синхронизируемся.

Пока скачать StarWind Enterprise HA 5.6 нельзя, но совсем скоро это можно будет сделать с официального сайта.

Как вы догадываетесь, сейчас пойдет речь о самом лучшем средстве для создания хранилищ iSCSI для виртуальных машин VMware и Hyper-V, конечно же - о продукте StarWind Enterprise. Мы уже много рассказывали о нем в разделе про StarWind, но советуем вам повторить здесь, тут и тут, а также почитать инструкцию по установке отказоустойчивого кластера хранилищ iSCSI для VMware vSphere.

А сегодня мы поговорим о том, какие пути есть, чтобы получить StarWind Enterprise HA. Раньше, как вы помните был такой продукт как StarWind iSCSI Target Free Edition, который можно было использовать бесплатно с хранилищами до 2 ТБ. Но продукт был так хорош и удобен, что многие пользователи довольствовались бесплатной версией, даже не пробуя, что там есть в коммерческой - а было там много чего. Поэтому в итоге StarWind закрыл раздачу бесплатных версий, потому как компании созданы для того, чтобы зарабатывать деньги. Но не расстраивайтесь, я сейчас вам кое-чего расскажу.

А) Во-первых, весной прошлого года компания StarWind сделала официальное объявление о том, что для специалистов, получивших звание MVP, сертификацию MCT или MCP, а также звание VMware vExpert и сертификацию VCP/VCI - продукт StarWind предоставляется бесплатно. Единственное ограничение, которое само собой разумеется - это использование продукта в образовательных, демонстрационных или тестовых целях, но не в производственной среде. Сейчас в каждой более-менее нормальной компании, использующей виртуализацию, есть сертифицированные специалисты VCP, которые могут попросить лицензию и тестировать продукт сколько угодно долго, пока начальство не даст добро на покупку лицензии и запуск решения в промышленную эксплуатацию. Как получить лицензию? Нужно просто направить письмо с просьбой по адресу - vmware@starwindsoftware.com или hyper-v@starwindsoftware.com. По адресам, я думаю, понятно, кто куда должен слать письма.

Б) Второй немаловажный момент. Как и у всех, у компании StarWind есть пробный период в 30 дней для StarWind Enterprise HA. Поскольку это решение для создания отказоустойчивого кластера хранилищ для серверов ESX или Hyper-V, и вообще софт разносторонний, то вам этого месяца на тестирование может не хватить. Специально для этих случаев есть я. Вы можете написать мне письмо (areconster@gmail.com) с указанием того, на сколько вам нужна лицензия чтобы детально протестировать продукт. Само собой, я попрошу от Вас что-то взамен: это будет название Вашей компании и пара вопросов о Вашей виртуальной инфраструктуре VMware или Microsoft.

В) Ну и в-третьих, мы со StarWind'ом давние друзья, и, может быть, замутим в ближайшее время какие-нибудь конкурсы или иные мероприятия, где можно будет получить хорошую скидку на продукт StarWind Enterprise HA для своей виртуальной инфраструктуры. Оставайтесь на линии.

Ну и из нового - почитайте рекомендации по оптимизации настроек TCP/IP при эксплуатации хранилища iSCSI StarWind Enterprise для серверов ESX и Hyper-V (от MC Константина Введенского). Лишним не будет.

Компания Veeam даже в январе шевелится, в отличие от остальных тех, кто еще спит. Итак, новостей две. Во-первых, вышла вторая глава книги "The Expert Guide to VMware Data Protection and Disaster Recovery" от Eric Siebert. Глава называется "Backup and Recovery Methodologies":

Во-вторых, 20 января состоится вебинар "5 New ways to use SureBackup". Проводит его небезызвестный Rick Vanover, умеющий показать, что и как работает в деталях. Ну а для тех, кто хочет послушать о Veeam Backup and Replication 5 на русском - просим на вебинар "Познакомьтесь с Veeam Backup & Replication v5 и революционной технологией vPower", где Владимир Ескин расскажет вам о новой технологии SureBackup. И вообще, все вебинары Veeam на русском языке вы найдете здесь.

Многие пользователи, занимающиеся тестированием различных платформ виртуализации, особенно в крупных организациях, сталкиваются со следующей проблемой. Используются виртуальные машины на платформах различных вендоров (VMware vSphere и Microsoft Hyper-V, например), а потом эти тестовые машины сами собой входят в производственную среду. Потом компания принимает решение использовать одну платформу в рамках предприятия - и встает проблема конвертации виртуальных машин VMware в формат Hyper-V или (что чаще) наоборот.

Сделать это можно с помощью продуктов от самих этих вендоров, но они не всегда удобны, просты в обращении и бесплатны. А вот у компании StarWind есть полностью бесплатный продукт для преобразования виртуальных дисков между форматами VMDK и VHD - StarWind V2V Converter.

Просто подсовываете StarWind V2V Converter нужный VMDK / VHD диск виртуальной машины, а потом добавляете его к машине в клиенте vSphere или Hyper-V. Просто и удобно, а главное быстро. Данный продукт не вносит изменений в исходный образ, а также осуществляет надежное поблочное копирование в целевой образ виртуального диска.

Скачать полностью бесплатную версию StarWind V2V Converter можно по этой ссылке.

Константин Введенский, мой старый приятель и по совместительству сотрудник компании StarWind Software, опубликовал интересные заметки по оптимизации работы хранилищ виртуальных машин VMware ESX на базе продукта StarWind Enterprise. Если кто-нибудь из вас все еще не знает как StarWind может помочь вам в создании отказоустойчивых систем хранения по iSCSI для виртуальных машин серверов VMware ESX, то вам сюда, сюда, и, вообще, сюда.

О чем говорят нам эти заметки:

1. iSCSI Initiator на VMware ESX можно использовать в режиме NIC binding (то есть Teaming в настройках vSwitch), или в режиме MPIO (multipathing, в настройках политики путей к хранилищу в категории Storage), но нельзя их использовать одновременно. Еще посмотрите сюда.

2. Если вы используете и хранилища NAS/NFS, и хранилища iSCSI, то нужно использовать NIC Teaming для обоих интерфейсов, а не MPIO.

3. Для типа балансировки IP Hash вы сможете использовать только 1 iSCSI-соединение на хост VMware ESX. Как настраивается тип балансировки IP Hash изложено в KB 100737.

4. По умолчанию время выбора пути в случае отказа на VMware ESX равно 300 секунд. Это время рекомендованное VMware. Вы можете уменьшить или увеличить это время. Его уменьшение ускорит переключение на резерв, но даст нагрузку на процессор ESX (более частый опрос путей), увеличение этого времени снизит нагрузку на CPU, но и увеличит время Failover'а. Настраивается этот параметр в Advanced Settings сервера ESX - он называется Disk.PathEvalTime, и его значение может варьироваться в диапазоне от 30 до 1500. Более подробно в VMware KB 1004378 и еще вот тут посмотрите, например.

5. В виртуальных машинах Windows убедитесь, что параметр Disk\TimeOutValue в реестре равен 60 секундам. Это позволит дисковому устройству не отваливаться раньше времени. Если VMware Tools установлены, то он будет равен 60 секундам после установки, если же нет, то это будет 10 секунд (non-cluster) или 20 секунд (cluster node). Настраивается он вот в этом ключе реестра:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Disk\TimeOutValue

Для Linux все немного не так. Без VMware Tools время TimeOutValue равно 60 секундам, а с ними - 180 секундам. Настраивается TimeOutValue в Linux так:

cat /sys/block/<disk>/device/timeout

Для большинства случаев подойдет значение в 60 секунд.

6. Для достижения лучшей производительности со StarWind Enterprise лучше использовать политику балансировки нагрузки по нескольким путям Round Robin (не активирована по умолчанию, по дефолту стоит политика Fixed). Для этого нужно щелкнуть правой клавишей по устройству iSCSI и нажать "Manage Paths" в vSphere Client.

Эта политика позволяет переключаться между путями каждые 1000 IOPS'ов. Можно уменьшить это значение для оптимизации производительности. Для этого в сервисной консоли ESX / ESXi наберите:

esxcli nmp roundrobin setconfig --device [UUID] --iops 3 --type iops

В данном случае выставлено 3 IOPS'а. UUID девайса можно узнать в категории "Storage adapters" в vSphere Client для сервера ESX. Опросить текущие настройки устройства можно командой сервисной консоли:

esxcli nmp roundrobin getconfig --device [UUID]

Ну и, конечно, помните, что все эти настройки нужно сначала опробовать в тестовой среде и посмотреть на изменения в производительности работы сервера ESX с хранилищем StarWind Enterprise.

Скачать StarWind Enterprise HA можно по этой ссылке, ну а покупают его только здесь.

Помните мы писали о замечательном человеке Романе, который делает переводы технических документов NetApp, которые дают много полезной информации не только пользователям СХД этого вендора, но и раскрывают общие принципы использования хранилищ для физической и виртуальной инфраструктуры.

Теперь у нас есть еще один документ на русском языке - "Руководство по наилучшим способам использования систем NetApp с VMware vSphere 4.1".

А вот что есть еще интересного о виртуализации на русском языке (остальное - здесь):

Использование NFS в VMware 
Bikash Roy Choudhury | NetApp | Июль 2010 | TR-3839 
В данном документе рассматриваются потенциальные преимущества использования в инфраструктуре хранения VMware работы по Network File System (NFS) с системы хранения NetApp®.
Скачать .pdf (22 страницы) html

Интеграция NetApp с VMware vStorage API
Robert McDonald | NetApp | Июль 2010 | WP-7106 
Этот документ описывает набор поддерживаемых в NetApp средств VMware® vStorage APIs for Array Integration (VAAI). VAAI это набор API, позволяющих виртуализованной инфраструктуре на базе VMware vSphere™ тесно интегрироваться с системой хранения. 
Скачать .pdf (8 страниц) 

Наилучшие методы использования систем хранения NetApp для решений виртуализации Microsoft Hyper-V
Chaffie McKenna, NetApp | Ravi B, NetApp | Декабрь 2009 | TR-3702-1209 
Этот документ содержит руководство и описание наилучших методов для построения интегрированной архитектуры и внедрения Microsoft Hyper-V с использованием систем хранения NetApp. Технологии NetApp, рассматриваемые в этом руководстве важны для создания эффективного с точки зрения затрат, производительности, гибкости и дружественности к окружающей среде интегрированного решения хранения данных виртуальной серверной инфраструктуры. 
Скачать .pdf (105 страниц)

Руководство по наилучшим способам использования систем NetApp с VMware Virtual Infrastructure 3
M. Vaughn Stewart, Michael Slisinger, Larry Touchette, | NetApp | TR 3428
Перевод Р. Хмелевского
Данный документ рассматривает наилучшие методы решений при внедрении VMware Virtual Infrastructure с использованием системы хранения Network Appliance FAS. Полезные советы, особенности установки и настройки, как на стороне системы хранения, так и на стороне VMware ESX/VI.
Скачать .pdf (76 страниц) 

Мы уже много писали о продукте StarWind Enterprise HA, который позволяет создавать отказоустойчивые хранилища для серверов виртуализации VMware ESX на базе обычных Windows-серверов. Недавно вышла версия StarWind Enterprise HA 5.5, в которой реализован канал Heartbeat для еще большей надежности продукта. В данной статье рассматривается весь процесс создания отказоустойчивого кластера StarWind, который выдерживает отказ одного из узлов, отвечающего за работу с томами VMFS для серверов ESX / ESXi.

Как многие из вас знают, есть такой замечательный продукт StarWind Enterprise, который позволяет создать отказоустойчивый кластер хранилищ для виртуальных машин VMware vSphere. Об этом продукте у нас есть целый раздел, но наиболее полезные страницы - это эта, эта, эта и эта.

Схема организации кластера высокой доступности хранилищ StarWind Enterprise выглядит так:

То есть, каждый из узлов StarWind должен иметь, по крайней мере, 2 сетевых интерфейса - для доступа хост-серверов виртуализации к хранилищу и для синхронизации данных узлов между собой (чтобы работа продолжилась в случае отказа одного из узлов - данные пишутся на узлы синхронно). Но само собой, 2 интерфейса - это очень ненадежно и небыстро. Поэтому лучше делать NIC Teaming и для канала синхронизации (надежность), и для канала работы с хранилищем по iSCSI (скорость). Поэтому, по-хорошему, нужно 4 интерфейса.

Вы уже все, конечно же, скачали версию StarWind Enterprise 5.5 и приступили к ее установке. Где определяются параметры сетевых интерфейсов? Запустим, например, мастер создания виртуального диска, работающего в режиме высокой доступности (High Availability):

Здесь указываются параметры сервера-партнера в кластере высокой доступности. Имя или IP-адрес, который сюда вводится - это и есть интерфейс узла, через который происходит доступ со стороны хост-серверов VMware ESX (то есть то, что на предыдущей картинке сверху). А вот в этом шаге мастера:

В поле "Интерфейс" указывается IP-адрес интерфейса, по которому происходит синхронизация узлов между собой (то, что на первой картинке сбоку). Кроме того, в версии 5.5 появилось новое поле Heartbeat - это интерфейс, через который два узла кластера Heartbeat обмениваются сигналами доступности, чтобы при обрыве канала синхронизации не возникло ситуации Split Brain (понять что это такое вы можете из статьи "Новая возможность StarWind Enterprise HA - устранение ситуации Split Brain"). Вот в поле Heartbeat этот адрес и нужно задавать. Само собой, лучше, если подсеть heartbeat у вас будет отдельная в целях повышения надежности.

Кстати, заметьте, что есть галка "Auto synchronization after failure", которая позволяет в случае отказа одного из узлов, а потом ввод его в строй (например, перезагрузка) автоматически синхронизировать узлы между собой. Раньше это делалось только вручную.

И еще одно - вы уже заметили, что на картинках меню на русском языке. Переключается язык тут:

Мелочь, а приятно.

Вы конечно уже слышали, что вышла новая версия StarWind Enterprise 5.5, предоставляющая еще больше возможностей для создания отказоустойчивых хранилищ iSCSI для хост-серверов виртуализации VMware vSphere / ESX (больше тут, тут и тут).

Создавать iSCSI-хранилища с помощью этого продукта вы можете на любом Windows-сервере, к которому может быть подключено локальное хранилище (свои диски или DAS), либо общее хранилище (Fibre Channel / NFS / iSCSI).

Только вот при установке StarWind Enterprise на Windows Server 2003 вы получите вот такое сообщение:

В Windows Server 2008 этот инициатор уже есть, а вот в Windows 2003 нужно установить Microsoft iSCSI Initiator для StarWind. Для этого переходим по ссылке "Microsoft iSCSI Software Initiator Version 2.08" и устанавливаем его в Windows Server 2003:

после чего перезагружаем сервер.

И да, для тех кто уже имеет инсталляцию StarWind Enterprise HA. Как обновить продукт на версию 5.5:

1. Надо устанавливать версию StarWind 5.5 прямо поверх предыдущей (при этом хранилище для виртуальных машин будет оставаться доступным и прерывания их работы не произойдет).

2. Сначала обновляем первый узел кластера StarWind Enterprise HA.

3. Затем синхронизируем ноды между собой.

4. Обновляем второй узел и снова синхронизируемся.

В очень интересной презентации "Transitioning to ESXi with vSphere 4.1" от Mark'а Monce (которую неплохо бы просмотреть всем администраторам VMware ESX в связи со скорым обязательным переходом VMware на гипервизор ESXi) обнаружились интересные моменты:

1. Если через веб-браузер по https зайти на VMware ESXi по ссылке:

https://<hostname>/host

мы увидим его конфигурационные файлы:

2. Если зайти на VMware ESXi по адресу:

https://<hostname>/host/messages

мы увидим его лог-файлы:

3. А если сходить на ESXi по этому адресу:

https://<hostname>/folder

То мы увидим содержимое VMFS-томов:

Напишите в комментариях, пожалуйста, если что-то из этого не работает.

Сегодня должен быть доступен релиз продукта StarWind Enterprise HA версии 5.5, который позволяет превратить любой Windows-сервер в отказоустойчивое хранилище данных для хост-серверов VMware ESX или Microsoft Hyper-V, работающее по протоколу iSCSI (а значит, не надо вкладывать деньги в дорогостоящие Fibre Channel хранилища). Подробнее о продукте можно прочитать тут, тут, тут, тут и тут (и, вообще, есть для этого специальный раздел на сайте).

Новые возможности StarWind Enterprise HA 5.5:

• High Availability: Добавлена возможность устранения ситуации Split Brain (в случае обрыва канала синхронизации). Теперь в случае отсутствия связи между узлами по сети синхронизации StarWind обрабатывает эту ситуацию с помощью сигналов доступности (Heartbeat) по сети взаимодействия с хост-серверами.
  
  
  
  Если в этой сети обнаруживается, что второй узел доступен, а недоступен только канал синхронизации, то первичный узел кластера StarWind продолжает запись данных виртуальных машин, а вторичный узел отключает всех своих клиентов. Таким образом сохраняется целостность кластера и отсутствует потери данных, а также простои виртуальных машин. Тем не менее, для канала синхронизации все равно лучше использовать несколько сетевых интерфейсов и NIC Teaming.
  
• High Availability: множественные улучшения производительности работы кластера StarWind.
  
• High Availability: поддержка собственной технологии Fast Sync для устройств работающих в режиме кэширования write-back (подробнее здесь). Эта технология позволяет в случае наступления события отказа одного из узлов кластера хранилищ StarWind, а затем его восстановлении (Failback) сделать быструю синхронизацию резервного узла с основным за счет передачи только изменений с момента последнего "живого" состояния основного узла. А вообще методов кэширования в StarWind iSCSI есть два (и они, в зависимости от нагрузки, увеличивают производительность до 30-50%):
  
  
  
• High Availability: Если оба узла кластера хранилища StarWind iSCSI отказали или выпали из сети, и после этого начала работать полная синхронизация этих узлов, то устройства хранения будут доступны хост-серверам ESX или Hyper-V сразу же (до ее окончания). Данные будут записываться на узел, который выбран в качестве источника синхронизации (synchronization source).
• High Availability: Добавлена полная поддержка аутентификации в iSCSI SAN по паролю (CHAP authentication).
• CDP/Snapshots: Доработан механизм работы с дисками с GPT разделами.
• Virtual Tape: Исправлена ошибка, связанная с изменением образа файла virtual tape. Параметры устройства теперь показывают корректное имя файла. Если в устройство не загружено ни одного файла-образа Virtual Tape, то в свойствах отображается "None - Virtual Tape device is not loaded" и нулевой размер файла.
• GUI: Множество добавлений и исправлений в основное средство управления - Management Console.

Скачать пробную версию StarWind Enterprise HA 5.5 можно по этой ссылке. Ну а продается StarWind в компании VMC.

Многим из вас уже известно средство создания отказоустойчивых хранилищ для серверов VMware vSphere - StarWind Enterprise HA. Оно позволяет при минимальных вложениях создать инфраструктуру хранения данных для виртуальных машин на базе обычного Windows-сервера посредством технологии iSCSI и защитить ее от сбоев со стороны систем хранения (локальные диски серверов или общие хранилища).

Сегодня я хочу поговорить об экономической стороне дела. Не все организации из сектора среднего и малого бизнеса могут позволить себе дорогостоящие хранилища HP или EMC (и их дублирование!), при этом для некоторых сервисов очень важна высокая доступность на всех уровнях от сервера до хранилища. То есть они не могут простаивать ни минуты.

В VMware vSphere есть механизм защиты от сбоев серверов - VMware HA, который перезапустит виртуальную машину отказавшего или выпавшего из сети сервера на других серверах кластера. А вот как быть с хранилищами? Можно использовать StarWind iSCSI Target для создания VMFS-тома на локальном хранилище одного из физических серверов (или прицепленного к нему тома общего хранилища) - но это не убережет от сбоев. Можно использовать кластер StarWind Enterprise HA из двух серверов - тогда конфигурация будет отказоустойчивой со стороны хранилищ, но потребуются деньги на эти 2 сервера.

Некоторые организации нашли выход - они размещают виртуальные машины с установленным в них StarWind Enterprise HA на разных хостах ESX в кластере VMware HA и делают между этими ВМ кластер StarWind. Сами виртуальные машины со StarWind (с большими виртуальными дисками) лежат на разных физических хранилищах (например, это могут быть локальные диски каждого из хостов ESX).

Такая конфигурация, безусловно, дает некоторое падение производительности при работе с дисками - поскольку есть несколько уровней виртуализации хранилищ, но зато позволяет вообще без вложений обеспечить отказоустойчивость на уровне системы хранения. Тем более, что, например, локальные диски хостов ESX в этом случае работают достаточно быстро.

Если один хост ESX откажет - не беда его виртуальные машины автоматически перезапустятся с помощью VMware HA на другом хосте, а данные ВМ будут доступны со второго узла. Понятно, что на таких хранилищах можно держать не все виртуальные машины, а только те, за которые особенно страшно. Есть такие клиенты у StarWind, которые таким образом обеспечивают Server HA и Storage HA - и всем довольны.

И кстати - через какое-то время у StarWind будет VSA (Virtual Storage Appliance), который будет представлять собой такую вот виртуальную машину, используемую как хранилище, но на базе какого-нибудь Linux, а значит не придется тратить деньги на лицензию Microsoft Windows.

Пробную версию StarWind Enterprise HA можно скачать по этой ссылке.

Есть такая компания VMTurbo - они делают утилиты для виртуальной инфраструктуры VMware vSphere. Кое-что у них получается, кое-что нет, а вот на днях они выпустили 2 новых утилиты: Host Resolver 1.0 и Storage Reporter 1.0. Обе они построены на базе виртуальных модулей (Virtual Appliance) с ОС Novell SUSE Linux как часть пакета VMTurbo Integrated Management Suite для виртуальных сред VMware.

VMTurbo Host Resolver 1.0

Эта утилита позволяет проанализировать окружение серверов VMware ESX, выявить проблемы в существующей инфраструктуре и предложить пути их решения - типа изменить число виртуальных CPU или переконфигурировать сетевые настройки. После этого можно исправить ошибки вручную или автоматически с помощью данной утилиты.

VMTurbo Storage Reporter 1.0

Эта утилита позволяет проанализировать использование виртуальными машинами систем хранения, понять основные параметры производительности при работе со стораджами (IOPS, Latency) и отслеживать основные их параметры с течением времени (заполненность, снапшоты и прочее). Кроме того, может выдавать рекомендации по необходимости внесения изменений в конфигурации хранилищ (например, расширение).

Кстати, у этих ребят есть и бесплатные утилиты: VMTurbo Monitor и VMTurbo Watchdog.

В прошлой заметке мы писали о том, какие типы дисков бывают в продукте StarWind Enterprise, позволющем создать отказоустойчивую инфраструктуру хранения данных виртуальных машин серверов VMware ESX или Microsoft Hyper-V.

Сегодня мы посмотрим на мастер создания виртуального диска с поддержкой мгновенных снимков (снапшотов), который будет предоставлять доступ хост-серверам виртуализации по iSCSI. Снапшоты могут оказаться полезными при разработке и тестировании (временные снапшоты хранилищ виртуальных машин), а также для защиты данных от утери или сбоев в виртуальной инфраструктуре.

Для данного типа диска важен параметр Operation Mode, который задает режим его работы. Этот диск в StarWind Enterprise может работать в одном из четырех режимов:

• Growing Image (Thin Provisioning) - образ диска на физическом устройстве будет создан минимального объема (тонкий диск). Для серверов ESX он будет виден как полноценное хранилище указанного объема, а сам файл образа будет расти по мере его наполнения данными. Снапшот хранилища можно сделать только вручную. Для этого из контекстного меню для устройства на iSCSI Target надо выбрать пункт Create Snapshot. Этот режим работы диска подходит для создания снимков хранилища при тестировании каких-нибудь обновлений или глобальных изменений в прикладных системах виртуальных машин.
  
  

  

• Auto-Restored Snapshot - данный тип диска как раз подходит для разработки и тестирования. В таком режиме хранилище виртуальных машин во время одной сессии iSCSI будет изначально работать в режиме снапшота, а при окончании сессии - снапшот откатится к изначальному состоянию. Представьте, например, что вы тестируете связку систем на хранилище, но не хотите вносить изменения в эталонный виртуальный диск. Для такого диска можно задать лимит хранимых снапшотов (опция Limit maximum number of stored snapshots).
• Snapshot and CDP - в таком режиме StarWind будет автоматически создавать снапшоты хранилищ с заданным интервалом времени (опция Snapshot auto creation with interval of (minutes)). Такой тип диска полезен для постоянной защиты данных (Continuous Data Protection, CDP) хранилищ виртуальных машин от их утери или порчи. В случае сбоя можно откатиться к нужному снапшоту.
• Read-Only - такой диск будет доступен только для чтения, и для него нельзя будет создать снапшот. Этот диск подходит для создания хранилищ с какими-нибудь дистрибутивами или шаблонами, куда не потребуется вносить изменения.

Теперь что касается восстановления хранилищ из снапшотов. Пока восстанавливать их из интерфейса StarWind нельзя (как, например, дерево снапшотов в VMware vSphere). Чтобы восстановить хранилище, вам понадобится пересоздать iSCSI Target и указать существующих виртуальный диск снапшота в папке с данным диском. В скором времени нам обещают восстановление снапшотов из GUI продукта StarWind.

Скачать пробную версию ПО StarWind Enteprise HA можно по этой ссылке. Купить StarWind можно в компании VMC.

Как вы знаете, есть такой замечательный продукт StarWind Enterprise HA, который позволяет создать отказоустойчивое хранилище для серверов VMware vSphere или Microsoft Hyper-V с помощью технологии iSCSI на базе одного или двух обычных Windows-серверов (то есть не надо покупать дорогостоящие FC-хранилища и продукты для репликации данных). Мы уже писали о нем тут, здесь, там, в этой статье и много где еще. Сегодня мы посмотрим на то, в каких режимах могут работать хранилища StarWind Enterprise.

Итак, при добавлении iSCSI Target в StarWind Enterprise нам предлагают создать новый виртуальный диск. У нас есть три варианта создания диска:

Эти варианты работы iSCSI устройства StarWind отличаются следующим:

• В режиме Physical - мы монтируем физический диск сервера для создания iSCSI Target (то есть, с какой-либо файловой системой или без нее). На этом диске хост-серверы виртуализации VMware ESX уже сами будут создавать файловую систему (VMFS).
• В режиме Basic Virtual мы создаем виртуальный диск без функциональности снапшотов (то есть это просто файл на диске в операционной системе Windows Server с установленным StarWind Enterprise, в который будет происходить запись данных виртуальных машин, которые, в свою очередь, видят содержимое этого файла как хранилище iSCSI). Внутри этого файла уже самим сервером VMware ESX создается том VMFS. Данный диск может быть тонким (растущим по мере наполнения данными), но создать тонкий диск из GUI StarWind нельзя (будет в следующих версиях).
• В режиме Advanced Virtual - мы создаем диск с поддержкой мгновенных снимков и кластеризации. Такой диск работает как предыдущий за исключением возможностей защиты данных. К ним относятся зеркалирование образов дисков, снапшоты (мгновенные снимки) и диск с поддержкой двухузловой конфигурации StarWind (High Availability). Этот тип поддерживает возможность создания тонких (растущих по мере наполнения данными) дисков.

Далее есть три типа виртуальных дисков Advanced Virtual:

Они представляют собой следующие подтипы:

• Mirror (RAID-1) Device - это зеркалированный виртуальный диск, который может находиться на разных физических устройствах, подключенных к серверу хранения, что обеспечит защиту данных в случае отказа одного из этих устройств (например, разные диски или разделы разных массивов). Но узел StarWind, через который сервер VMware ESX будет получать доступ к хранилищу, будет один. Такой тип дисков подходит для защиты данных виртуальных машин от физических сбоев хранилищ, но не подходит для защиты данных от утери (например, удаление пользователем).
• Snapshot and CDP Device - это возможность создать хранилище виртуальных машин, которое поддерживает функциональность мгновенных снимков (snapshots). Эти снимки могут создаваться автоматически или вручную, что обеспечит возможность отката к определенному состоянию хранилища. Данный тип дисков также может работать в нескольких режимах обеспечения защиты данных. Также эти диски могут быть тонкими (растущими по мере наполнения данными). Кроме того, такой тип дисков может пригодиться, когда часто требуется откатываться к исходному состоянию хранилища, например, при разработке и тестировании.
• High Availability Device - данный диск совместим с двухузловой конфигурацией StarWind Enterprise HA, которая обеспечивает защиту данных виртуальных машин за счет резервирования и узлов, и их хранилищ. Эти узлы синхронизируют данные между собой и могут работать в Active-Active или Active-Passive конфигурации (подробнее здесь). Для такого диска указываются параметры сервера-партнера StarWind.

На этом пока все - в следующей заметке мы расскажем о типе дисков Snapshot and CDP Device - в каких режимах они могут работать, и как они могут применяться на практике.

Скачать пробную версию ПО StarWind Enteprise HA можно по этой ссылке. Купить StarWind можно в компании VMC.

Не секрет, что в мире виртуализации есть не только VMware. Многие пользователи, особенно из сегмента малого и среднего бизнеса, отдают предпочтение гипервизору Microsoft Hyper-V, который в составе Windows Server 2008 R2 приобрел множество полезных возможностей.

Технология построения отказоустойчивых хранилищ на базе ПО StarWind Enterprise отлично вписывается в сегмент СМБ, где при небольших инвестициях нужно получить максимум эффективности и функционала. Microsoft Hyper-V дешевле VMware vSphere (именно сам продукт, а не стоимость владения), а StarWind - не требует покупки дорогостоящих хранилищ и недешевого SAN-оборудования. Поэтому Microsoft Hyper-V и StarWind - отличные друзья.

Как многие помнят, у Hyper-V есть псевдокластерная файловая система CSV (Cluster Shared Volumes), которая представляет собой надстройку над NTFS и позволяет использовать общие тома для хранения виртуальных машин с поддержкой "горячей" миграции между хостами Hyper-V (Live Migration) и отказоустойчивости (High Availability). Система эта псевдокластерная потому, что для томов CSV из узлов Hyper-V в кластере выбирается узел-арбитр, который управляет SCSI-резервациями виртуальных машин (сам ввод-вывод идет напрямую).

При этом, у узлов Hyper-V есть такая интересная возможность, как Dynamic I/O Redirection. Эта техника позволяет в случае отказа пути одного из узлов Hyper-V к IP-сети хранения перенаправить его ввод-вывод через узел-арбитр. То есть в случае отказа всех путей хост-сервера к SAN виртуальные машины продолжают свою работу на этом узле до того, пока они не переедут на другой узел за счет технологии Live Migration (картинка уж извините от NetApp):

Если же отказ произойдет внутри iSCSI SAN, то там уже свою работу делает StarWind Enterprise HA, который переключается на резервную ноду без простоя в случае отказа основного узла хранилища.

Понятное дело, что ситуация, описанная выше с Hyper-V для Dynamic I/O Redirection, полезна лишь в очень ограниченном количестве случаев, когда, например, подключения узла к SAN не дублированы (да, и такое бывает).

Мы рекомендуем использовать StarWind Enterprise для конфигураций Hyper-V, когда требуется создание надежной и защищенной инфраструктуры хранения для виртуальных машин. Что еще можно почитать на эту тему от StarWind:

• StarWind iSCSI SAN for Microsoft Windows: Configuring High Availability storage for Windows Server 2003 and 2008
• Как работает StarWind Enterprise HA
• StarWind iSCSI SAN Software: Using StarWind with MS Cluster on Windows Server 2003
• StarWind iSCSI SAN Software: Using StarWind with MS Cluster on Windows Server 2008
• StarWind iSCSI SAN Software: Using StarWind to Provide Cluster Shared Disk Resources for Hyper-V Failover Clusters

Скачать пробную версию ПО StarWind можно по этой ссылке.

Компания Veeam Software, ведущий поставщик средств для управления виртуальной инфраструктурой VMware vSphere, объявила о выпуске средства для резервного копирования виртуальных машин на серверах VMware ESX / ESXi - Veeam Backup and Replication 5.

Это действительно новый и революционный продукт, выводящий на новый уровень технологии резервного копирования виртуальных машин. Теперь оно стало еще более эффективным, а, с точки зрения механизмов восстановления данных и надежности, на сегодняшний день Veeam Backup and Replication 5 - абсолютный лидер в сегменте продуктов для резервного копирования VMware vSphere.

Мы уже писали об основных нововведениях Veeam Backup and Replication 5 с технологиями vPower, SureBackup, U-AIR и другими в следующих статьях:

• vPower - новые возможности Veeam Backup and Replication 5
• Демонстрация технологии SureBackup в Veeam Backup and Replication 5
• Издания Veeam Backup and Replication 5 - обзор возможностей
• Veeam SureBackup - новые возможности Veeam Backup and Replication 5

Теперь обо всех новых функциях и возможностях Veeam Backup and Replication 5 расскажем по порядку:

1. Технология Veeam vPower в Veeam Backup and Replication 5.

Используя множество техник, компания Veeam в своем продукте для резервного копирования виртуальных машин сделала возможность запуска их напрямую из резервных копий, которые хранятся в дедуплицированном виде на backup-хранилище. Это создает множество возможностей для тестирования резервных копий на работоспособность (SureBackup), мгновенного восстановления в производственную среду (InstantRestore) и даже управления виртуальными тестовыми лабораториями на базе продуктивных окружений (то есть, можно запустить продуктив напрямую из бэкапа для каких-нибудь тестов). Таким образом, Veeam vPower - это фундаментальная технология для множества улучшений в Veeam Backup and Replication 5.

2. Техника Instant VM Recovery (InstantRestore) в Veeam Backup and Replication 5.

InstantRestore позволяет мгновенно (без копирования каких-либо данных) восстановить резервную копию системы, запустив ее напрямую из резервной копии, которая хранится в сжатом и дедуплицированном виде. Далее виртуальная машина потихоньку переносит свое хранилище в продуктивную среду за счет технологии Storage VMotion. Если по лицензии VMware vSphere у вас нет техники Storage vMotion, то можно использовать репликацию виртуальной машины в производственное окружение - ведь репликация в Veeam Backup and Replication 5 бесплатна! Все это влияет самым лучшим образом на политики RTO (Recovery Time Objective) сервиса в виртуальной машине, позволяя восстановить его сразу после отказа.

3. Техника U-AIR (Universal Application-Item Recovery) в Veeam Backup and Replication 5.

U-AIR позволяет восстанавливать объекты приложений виртуальных машин напрямую из образа резервной копии. То есть, из бэкапа можно достать и восстановить на целевой сервер объект Active Directory, письмо Exchange или любой другой объект приложения. Кроме того, есть возможность самостоятельного восстановления данных пользователем из приложений с веб-фронтендом. Заметьте - не надо никаких агентов для восстановления отдельных объектов.

4. Техника SureBackup в Veeam Backup and Replication 5.

Veeam SureBackup позволяет убедиться в том, что резервные копии сделаны правильно и они полностью готовы к восстановлению и работе в случае аварии или потери данных. Делается это автоматизированным способом за счет создания виртуальной тестовой лаборатории, где виртуальные машины запускаются напрямую из бэкапов, не мешая основной производственной среде. Далее администратор вручную или автоматически (по заданию) верифицирует целостность хранимых копий, в том числе с помощью специальных скриптов, которые проверяют работоспособность не только ОС, но и приложений. Об отработавшей задаче проверки целостности резервных копий системному администратору приходит отчет по почте.

5. Виртуальная лаборатория по запросу (On-Demand Sandbox) в Veeam Backup and Replication 5.

С помощью техник мгновенного запуска резервных копий администратор может запустить набор приложений в виртуальных машинах, являющихся копией производственной среды, и проводить там какие угодно тесты. Для тестовой лаборатории задается хост ESX / ESXi, где это будет происходить, Datastore, Proxy Appliance для доступа Veeam Backup к тестовой лаборатории с виртуальными машинами в изолированной сети и настройки этой самой сети. После того, как виртуальная лаборатория создана, появится новый виртуальный коммутатор vSwitch, пул ресурсов и хранилище для тестирования.

6. Мгновенное восстановление файлов (Instant File Level Recovery) для любой гостевой ОС в Veeam Backup and Replication 5.

Veeam Backup всегда умел восстанавливать отдельные файлы из бэкапов гостевых систем виртуальных машин. Windows, Linux, FreeBSD и многое другое поддерживается для восстановления (при этом есть удобный навигатор по файловой системе). Теперь также появляется еще одна интересная возможность - монтирование диска резервной копии к виртуальной машине, куда требуется восстановить нужные файлы. Это очень удобно, а восстановление занимает считанные секунды.

7. Быстрый поиск объектов (Instant Indexing) в Veeam Backup and Replication 5.

Функция Instant Indexing - это быстрая индексация данных содержимого резервных копий виртуальных машин, что позволяет быстро искать в бэкапах любые файлы и мгновенно вытаскивать их в продуктивную среду. Также есть удобный браузер по файловым системам в Veeam Enterprise Manager.

• Customizable block size. Теперь можно настраивать размер блока для хранилища назначения резервной копии или реплики. Большой размер блока уменьшает затраты вычислительных ресурсов на бэкап и повышает производительность, в то время как меньший размер блока увеличивает степень дедупликации и позволяет уменьшить передаваемый трафик (что особенно актуально для WAN-соединений) при инкрементальном резервном копировании.
• Monthly schedules. Теперь можно настроить планировщик по месяцам для задач резервного копирования напрямую из GUI, который предоставляет больше опций нежели стандартный планировщик Windows.
• Continuous job schedule. Новая возможность создания задач по расписанию для соответствия сценариям near-CDP protection.
• Unsupported disks are now automatically skipped. Неподдерживаемые диски для резервного копирования теперь автоматически пропускаются (раньше надо было исключать их из задачи вручную).

• Incremental backup mode. Традиционный режим инкрементального резервного копирования теперь тоже есть для поддержки сценариев резервного копирования disk-to-disk-to-tape (D2D2T), удаленных сайтов и на хранилища, которые дедуплицируются своими средствами. Синтетический режим резервного копирования (обратные инкременты) также остался. Кроме того, можно восстанавливать систему даже тогда, когда отрабатывает задача по резервному копированию.
• Previous full backup chain transformation. Возможность преобразовать цепочки предыдущих полных бэкапов (Full Backups) в цепочку с одним полным бэкапом и несколькими обратными инкрементами для экономии дискового пространства на целевом хранилище.
• VM level retention in full backup files. Теперь в файле полной резервной копии просто заменяются блоки данных в соответствии с настроенной политикой хранения полных резервных копий. То есть, нет необходимости делать полный бэкап, полностью удаляя предыдущий из VBK-файла.
• Delete individual VMs from full backup file. Теперь можно удалить любую виртуальную машину из резервной копии с VBK-файлом. Блоки помечаются как свободные, и на их место записываются дальнейшие данные бэкапов без роста размера файла.
• Enhanced backup properties. Расширенные настройки в опциях для задачи резервного копирования.

• Thin disk support on replica. Теперь у реплики также может быть растущий по мере наполнения данными (thin) диск. Это улучшает производительность репликации.
• On-the-fly disk transformation. Также можно на лету при репликации преобразовывать "толстые" (thick) диски исходной машины в тонкие (thin) диски реплики. Экономия на дисковом хранилище реплик.
• Replica properties. Появились новые свойства реплики, такие как объем данных переданный с после запуска задачи репликации (функция, о которой запрашивали многие пользователи).

• Network connection-less operation. Теперь нет необходимости прямого соединения виртуальной машины, где работает Veeam VSS Agent, и бэкап-сервера. Это позволяет соблюсти политики безопасности в виртуальной инфраструктуре без потери функциональности по обеспечению целостности данных за счет служб VSS.
• Granular application-aware processing. Теперь можно более структурированно задавать настройки выполнения различных задач (например, запуск службы VSS) для отдельных виртуальных машин или других объектов виртуальной инфраструктуры VMware vSphere.
• Better transaction logs handling. Теперь лог транзакций приложения резервируемой системы очищается только после успешного бэкапа, вместо того, чтобы делать это после снятия снапшота при создании резервной копии. Это позволяет сохранить лог транзакций и откатиться на нужную точку в Microsoft SQL Server, даже если задача резервного копирования по какой-либо причине упадет после снятия снапшота виртуальной машины.
• Option to disable transaction logs pruning. Можно также полностью отключить очистку лога транзакций.
• Transaction logs pruning for Microsoft SQL. Очистка лога транзакций для Microsoft SQL Server была введена на случай, если этот сервер резервируется только средствами Veeam Backup и требуется, чтобы логи транзакций не разрастались.

• VM search. В мастер восстановления добавлена возможность поиска файлов, чтобы быстро найти файлы, которые требуется восстановить из резервной копии виртуальной машины.
• Restore reason. Можно указать причину восстановления файла - удобно для администраторов, отслеживающих эти события.
• Restore audit. Теперь в логе восстановления видно, кто и какие файлы восстанавливал, а также по какой причине.
• Service-based restores. Теперь задача восстановления файлов управляется службой Windows, поэтому даже если пользователь вышел из системы - задача продолжится.
• Original VM location prefill. Мастер восстановления теперь предлагает по умолчанию куда восстанавливать виртуальную машину, чтобы пользователь не ошибся.
• Per-disk datastore selection. Для виртуальной машины с несколькими виртуальными дисками можно указать разные хранилища (datastores) для каждого диска.
• Better guest file permission handling. Теперь для задачи восстановления файлов добавляется привилегия для доступа к томам, на которые у пользователя нет разрешений. Делается это только для движка Veeam Backup и не нарушает политик безопасности.
• Removed VMware Player requirement. Виртуальный модуль File level restore helper appliance теперь запускается напрямую на хосте VMware ESX / ESXi. Теперь не надо использовать VMware Player на сервере Veeam Backup.
• Preserve Linux permissions. Теперь можно сохранить права доступа в Linux при восстановлении отдельных файлов.
• Permissions and ownership display. Браузер по файловой системе теперь показывает разрешения и владельца файлов.
• ZFS support. Восстановление файлов с томов ZFS теперь поддерживается.

• Datastore based jobs. Теперь можно создавать задачи, добавляя Datastore как объект для резервирования. Все машины на этом хранилище будут добавлены в задачу.
• Granular disk exclusions. Вместо того, чтобы настраивать исключения для дисков на базе задач, можно настраивать исключения на уровне виртуальных машин или других объектов виртуальной инфраструктуры VMware vSphere. Например, в каком-то пуле вы хотите исключить бэкап диска D виртуальных машин.
• Per-job email notification. Для каждой задачи отдельно можно настроить нотификацию по e-mail (для разных пользователей).
• Windows Event Log events.Veeam Backup теперь пишет о своих действиях в журнал Windows event log (в стиле vCenter).
• Simple delegation. Механизм доступа на базе ролей в Veeam Backup был добавлен для разграничения действий пользователей. Например, Restore Operator может выполнять любой тип восстановления, однако не может работать с задачами резервного копирования.
• Source datastore monitoring. Как вы знаете, снапшоты требуют дополнительное пространство на хранилище при создании и слиянии. Теперь мониторинг исходного хранилища позволяет убедиться в том, что не возникнет ситуации переполнения, когда из-за нее виртуальные машины завершат работу. По умолчанию, предупреждение высвечивается в случае, если остается менее 10 ГБ свободного пространства. Если остается менее 2 ГБ - задача резервного копирования будет пропущена.
• Session history improvements. Старые сессии восстановления теперь удаляются на базе политики хранения, что актуально для пользователей старых версий Veeam Backup, у которых много чего накопилось с более ранних версий.

• Centralized license management. Теперь удобно отслеживать использующиеся лицензии на Veeam Backup на нескольких серверах из центральной консоли Veeam Enterprise Manager.
• Dashboard statistic improvements. Теперь информация о занимаемом пространстве резервными копиями более детальна.

• Database name selection. Теперь можно привязать несколько бэкап-серверов Veeam Backup к одной базе Microsoft SQL.
  Disabling automount. Теперь автомонтирование новых томо автоматически отключается на сервере Veeam Backup при установке, чтобы предотвратить переподписку VMFS-томов со стороны Microsoft Windows. Теперь этого не надо бояться забыть сделать вручную.
  CPU verification. Теперь проверяется, достаточно ли мощности CPU для установки Veeam Backup. При этом требования к CPU сохранились от предыдущей версии.

Безусловно, Veeam Backup and Replication 5 - лучший продукт для резервного копирования виртуальных машин в инфраструктуре VMware vSphere. Скачать его можно по этой ссылке.

Купить Veeam Backup and Replication 5 можно уже сегодня. Для этого используйте форму заказа у Золотого партнера Veeam Software на территории России - компании VMC.

Как вы знаете, есть замечательное ПО StarWind Enterprise HA, которое позволяет создать отказоустойчивое хранилище для виртуальных машин VMware vSphere или Microsoft Hyper-V, на базе технологии iSCSI. Мы уже писали о StarWind здесь, здесь, здесь и здесь, а сегодня мы расскажем о том, какие требования к узлам предъявляет ПО StarWind Enterprise.

CPU

Рекомендуется процессор Intel Xeon E5620 или выше либо эквивалентный ему AMD Opteron. Надо отметить, что рекомендуется использовать многоядерные CPU. При этом, если сравнивать CPU, у которого частота каждого из ядер меньше, с CPU с большей частотой ядер, но меньшим их количеством - то предпочтителен первый вариант. То есть, лучше иметь 6-ядерный Intel Xeon 5660 с частотой 2.8 ГГц на ядро, чем 4-ядерный Intel Xeon 5667 с частотой 3.02 ГГц на ядро.

RAM

Минимум нужно 4 ГБ (для самой Windows и движка StarWind). Если вы используете один из методов кэширования в StarWind - то потребуется дополнительная память на кэши, исходя из их размеров.

Network

Естественно нужно использовать как минимум гигабитную сеть хранения iSCSI (при этом помните, что каждый компонент сети должен поддерживать 1 Гбит). Лучше использовать NIC Teaming для расширения канала или сети 10G, а также большие кадры Jumbo Frames (9K). Помните, что канал синхронизации между узлами обязательно нуждается в дублировании.

HDD

Можно использовать устройства SATA, SAS или SSD. Естественно, используйте аппаратные RAID-массивы, а не программные в производственной среде. Узнавать о том, какой RAID лучше начните отсюда.

Операционная система

Рекомендованная - Windows Server 2008 R2. Можно использовать и Windows Server 2003 (все, что выше - поддерживается). Также можно использовать и издания Server Core и даже бесплатный Hyper-V Server, однако, по понятным причинам, GUI для StarWind нужно будет устанавливать на отдельный компьютер (этот компонент называется StarWind Management Console). При этом для управления можно использовать и рабочую станцию с ОС, начиная с Windows XP. Помните, что для управления надо открыть порт 3261 в сетевом экране.

Сам процесс установки и настройки ПО StarWind Enterprise на каждом из узлов занимает 10-30 минут, поэтому просто возьмите и попробуйте продукт бесплатно.

Кстати, вроде бы из нового - появился вот такой документ "How to Increase VMware Application Availability with Shared Storage". И да, обязательно смотрите вот сюда и сюда.